…cess#14439.

Define 'processorArchitecture' property in WinVersion class to store machine arcthiecture for the Windows installatoin (x86/32-bit, AMD64, ARM64). This is useful in detecting 64-bit systems and different architectures for use for log output, 64-bit versus 32-bit differences, and testing and debugging.

…#14439.

Print processor architecture for the Windows installation as part of Windows version output.

…ine() function. Re nvaccess#14439.

Python's platform module provides platform.machine() function, returing the processor architecture for the system. If Windows is detected, it internally retrieves PROCESSOR_ARCHITEW6432 and PROCESSOR_ARCHITECTURE environment variabls, in that order so it can detect WoW64 (such as x86 program running on an x64 processor). Because winVersion.getWinVer() function caches the current Windows installatoin, processor architecture string is always available and cached as part of the resulting WinVersion object. The practical implication is that NVDA no longer needs to consult environment variables every time it wants to detect processor architecture as the result is already known at program startup.

…r. Re nvaccess#14439.

Add winVersion.getWinVer().processorArchitecture test to see if what it says matches processor architecture (and WoW64 version) environment variable. Python's platform.machine() function is not used because that function consults environment variables itself.

Closes #14439
Follow-up to #14397
Follow-up to #14403

Summary of the issue:
winVersion.WinVersion class should define processor architecture property to record machine architecture for the current Windows installation.

Description of user facing changes
At NVDA startup, processor architecture will be logged as part of Windows information.

Description of development approach
Add "processorArchitecture" property to winVersion.WinVersion class to record machine architecture (currently x86 (32-bit) AMD64 (x64), ARM64). From getWinVer() function, this value will be fetched via Python's platform.machine() function, which itself looks up processor architecture from environment variables. This means NVDA can read the new property instead of consulting environment variables every time it wishes to check machine architecture. Also, added a unit test to see if the processor architecture recorded is indeed the one Windows says.

Commits:

* winVersion.WinVersion: define processor architecture property. Re #14439.

Define 'processorArchitecture' property in WinVersion class to store machine arcthiecture for the Windows installation (x86/32-bit, AMD64, ARM64). This is useful in detecting 64-bit systems and different architectures for use for log output, 64-bit versus 32-bit differences, and testing and debugging.

* WinVersion.repr: print processor architecture if defined. Re #14439.

Print processor architecture for the Windows installation as part of Windows version output.

* winVersion.getWinVer: obtain processor architecture via platform.machine() function. Re #14439.

Python's platform module provides platform.machine() function, returning the processor architecture for the system. If Windows is detected, it internally retrieves PROCESSOR_ARCHITEW6432 and PROCESSOR_ARCHITECTURE environment variabls, in that order so it can detect WoW64 (such as x86 program running on an x64 processor). Because winVersion.getWinVer() function caches the current Windows installation, processor architecture string is always available and cached as part of the resulting WinVersion object. The practical implication is that NVDA no longer needs to consult environment variables every time it wants to detect processor architecture as the result is already known at program startup.

* Unit tets: add processor architecture test and update copyright header. Re #14439.

Add winVersion.getWinVer().processorArchitecture test to see if what it says matches processor architecture (and WoW64 version) environment variable. Python's platform.machine() function is not used because that function consults environment variables itself.

* update changes

Co-authored-by: Sean Budd <sean@nvaccess.org>